Skip to content
This repository has been archived by the owner on Jan 11, 2024. It is now read-only.

Fendermint [247, 248, 249]: Checkpoint signatures #202

Merged
merged 14 commits into from
Sep 21, 2023
Merged

Conversation

dnkolegov
Copy link
Contributor

@dnkolegov dnkolegov commented Sep 15, 2023

@dnkolegov dnkolegov marked this pull request as draft September 15, 2023 18:23
@aakoshh aakoshh changed the base branch from dev to membership September 18, 2023 09:50
Comment on lines 36 to 38
event SignaturesUpdated(uint256 h, bytes32 pof, Membership membership, bytes signature);
event SignatureInvalid(uint256 h, bytes32 pof, Membership membership, bytes signature);
event PoFThresholdReached(uint256 h, bytes32 pof, Membership membership, uint256 threshold);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are h and pof? If h is block height, shouldn't it be uint64? Does it cost anything to have longer field names?

A rule of thumb was to make field names which are long lived more verbose, and only use single letters for short-lived local variables.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for solidity, we have a convention to use U256 for block number.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cryptoAtwill but we use uint64 in all mappings mapping block numbers

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's the thing. In fvm, it's either u64 or i64, but in solidity, it's U256. How we do this previously is just use U256 in solidity as it's the convention. Then in rust, we convert to whatever is the preferred type. I don't feel we will run into overflow though. But feel free to suggest otherwise.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like just a dogmatic choice that is a forever thorn in one's side of how to handle the potential conversion errors, and takes up more space, but if that's how you want it 🤷

Copy link
Contributor Author

@dnkolegov dnkolegov Sep 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but in solidity, it's U256

@cryptoAtwill In the Solidity actors we also use uint64 as far as I see


if (signerExists) {
uint256 threshold = s.bottomUpCollectedSignaturesThreshold[h][pof];
threshold += membership.validators[signerIndex].weight;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be written back to the storage?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry what was the fix? I'm not a Solidity storage buff; it looks like you can take records and modify them and expect them to be persisted, I'm just checking if that's the case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The fix is to use "storage" type instead of "memory" type. But it was not fixed actually in that sense. Fixed now. Thank you.

@dnkolegov dnkolegov requested a review from aakoshh September 18, 2023 21:28
@aakoshh aakoshh changed the title Fendermint issue 247: signatures Fendermint issue 249: signatures Sep 19, 2023
Copy link
Contributor

@aakoshh aakoshh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good now, just minor comments and questions 👍

@dnkolegov
Copy link
Contributor Author

This looks good now, just minor comments and questions 👍

Great catches!
Thank you @aakoshh !

revert CheckpointMembershipNotCreated();
}

bytes32 checkpointHash = checkpoint.toHash();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a difference btw checkpointHash and checkpointInfo.hash?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the checkpoint is read from storage, that means we can storage the checkpointHash in storage as well? So that we dont have to compute it every time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot checnge that one. Thanks!

uint256 weight,
bytes memory signature
) external {
BottomUpCheckpointNew memory checkpoint = s.bottomUpCheckpoints[height];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we do backward check? Like the height should not have already committed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current idea is to continue to allow accumulating signatures even if it has been committed. In this case, we update signatures and emit an event with updated weight. If I understood you right...

Copy link
Contributor

@aakoshh aakoshh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bullseye 🎯

@dnkolegov dnkolegov marked this pull request as ready for review September 20, 2023 18:31
@aakoshh aakoshh changed the title Fendermint issue 249: signatures Fendermint [247, 248, 249]: Checkpoint signatures Sep 21, 2023
@dnkolegov dnkolegov changed the base branch from membership to dev September 21, 2023 10:43
@dnkolegov dnkolegov changed the base branch from dev to membership September 21, 2023 11:43
@dnkolegov dnkolegov merged commit c3c26dc into membership Sep 21, 2023
@dnkolegov dnkolegov deleted the fendermint247 branch September 21, 2023 11:44
@@ -21,6 +21,39 @@ struct BottomUpCheckpoint {
bytes proof;
}

/// @notice A bottom-up checkpoint type.
// TODO: Remove old BottomUpCheckpoint, rename BottomUpCheckpointNew to BottomUpCheckpoint and update the codebase.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dnkolegov, @cryptoAtwill, are we tracking this TODO somewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -50,8 +50,9 @@ contract GatewayGetterFacet {
return s.networkName;
}

// TODO: remove or add a new getter
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dnkolegov, should we track this in an issue like the others TODO?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants